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When a match is found between offers to buy and to sell, the respective users are 
informed of the match (steps 4 and 5 of Figure 1) and are given each other's IP addresses by 
the server 10. The users can then communicate with one another directly in a peer-to-peer 
manner (step 6) to carry out the auction proper, in which a user intendmg to sell receives bids 
5 from a user wishing to buy. 

The first offer is retained by the server 10 after an initial match with another offer so 
that further incoming offers can also be matched with the first offer. In this way, more than 
one match can be found and more than one pair of participants can be put in contact with 
each other, as will be shown later in Figure 7: the most common result in that case is to have 

10 a sole seller receiving bids from more than one buyer or, in a 'reverse' auction, a sole buyer 
bidding to more than one seller. This encourages competition that benefits the sole seller or 
the sole buyer as the case may be. However, where more than one user seeks to sell a 
particular kind of item at a particular price and more than one user seeks to buy that kind of 
item at that price, it is of course possible for multiple-seller, multiple-buyer communications 

1 5 to take place, peer-to-peer, creating a group of parallel auctions that match supply and 
demand. 

The auction can either be automatic or Kve depending on the users' preferences. If 
the former, the seller receives bids from one or more bidders and when a predetermined 
threshold has been reached, expressed as a bid value (e.g. a reserve price) and/or a time (e.g. 

20 a predetermined auction duration), the sale is agreed automatically at the best prevailing bid. 
The respective users can then complete the transaction by exchanging the item for the agreed 
payment. If the latter, the seller receives bids from one or more bidders and those bids are 
displayed to the seller as they come in. The seller then has the opportunity to respond to a 
bidder by accepting, rejecting or retaining a bid, depending upon how the seller foresees the 

25 auction developing, with a view to maximizing the selling price. 

It is also possible for an auction to be automatic to one user and 'live' to another user. 
For example, automatic bidding can take place from buyer agents while the seller uses a 
seller agent to view and respond in real time to the incoming automatically-generated bids. 
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The description above based upon Figure 1 merely outlines the first embodiment of 
the invention; reference is now made to Figures 2 to 7 to describe the first embodiment in 
more detail. 

Figure 2 shows the user interface 11 of a client application, which runs on a user's 
5 client terminal as an entirely separate application from a standard web browser. All users of 
the system, whether buyers or sellers, have this client application. The application can be set 
to start automatically when a user logs in or boots-up their computer, or a user can simply 
start the application from their computer in the usual way. 

As shown in Figure 3, a user at client terminal A or B firstly logs in to the system 

1 0 with a usemame and password which is sent to the server 10 along with the IP address of the 
computing device that user is currently using as a client terminal (step 1). The server 10 
checks and vaUdates the usemame and password and stores the IP address in order to carry 
out further communications with the user. The server 10 reports the login result to the client 
and, if login was successful, sends to the user the offer criteria of any previous buyer and 

1 5 seller agents created by that user (step 2). Alternatively, these criteria may be stored and 
accessed locally on the user's client terminal. 

Returning to Figure 2, the user interface 1 1 of the client application has two main 
fields, namely a seller field 12 and a buyer field 13, that respectively display information on 
seller or buyer agents already in existence. In those fields 12 and 13, each agent can be 

20 identified by a user-assigned name or alias together with a description of the item being 
offered or sought (not shown). Clicking on the appropriate completed line of a field 12, 13 
calls up details of an existing agent, whereas clicking on a 'new seller' button 14 or a 'new 
buyer' button 15 allows the user to create a new agent whose name/alias and associated 
description then appear in a field 12, 13 as appropriate. 

25 Figures 4 and 5 show user interfaces of seller and buyer agents, designated by the 

reference numerals 16 and 1 7 respectively. For a new agent, the interface 16, 17 displays 
blank fields constituting a form ready for the user to enter data, whereas for existing agents, 
the fields already contain data that can be user-edited when the user interface is opened. The 
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interfaces 16, 17 shown in Figures 4 and 5 reflect new agents in which the fields have been 

filled in to complete the form, but the data has not yet been posted. 

Looking firstly at the seller agent interface 16 of Figure 4, the user has filled out the 

form in the fields shown. The first field 1 8 holds a short name or alias for the agent so that 
5 the user can identify that agent in future in the interface 1 1 of Figure 2 and hence distinguish 

it from other agents. The field 19 below is a limited-character description of the item that 

will be used for the purpose of matching with possible buyers. A pair of option buttons 20 

enable the user to specify whether the auction will be 'live' or 'automatic', and 'date', 'time' 

and 'reserve price' fields 21, 22 and 23 allow the user to enter further information about the 
10 auction such as its proposed time and date and the seller's reserve price. Finally, a 'post 

seller' button 24 and a 'cancel' button 25 allow the user to post new or amended ofFer-to-sell 

criteria or to abandon creation or editing of a seller agent. 

The buyer agent interface 17 of Figure 5 is broadly similar to the seller agent 

interface 16 of Figure 4. A buyer user gives a name to his or her buyer agent in field 26, 
15 describes the item sought by entering a limited-character description in field 27 and 

appropriate keywords in field 28, and enters the maximum price that he or she is prepared to 

pay in field 29. Option buttons 30 enable the user to tell the buyer agent to keep looking for 

a match for as long as that agent remains in existence (or a server-set timeout period expires) 

or, alternatively, when to report back that no match has been found. 
20 A 'start looking' button 3 1 and a 'cancel' button 32 allow the user to post new or 

amended offer-to-buy criteria or to abandon creation or editing of a buyer agent. 

Although not shown in the screen shots of Figures 4 and 5, a user can also attach 

images of an item the subject of an offer. It is envisaged that the image itself will not be sent 

to the server 10, only information about where that image is stored, for example on the user's 
25 client machine or elsewhere on the communications network. The image can then be 

downloaded in a peer-to-peer fashion later in the process. 

Once the forms for a buyer or a seller agent are created and offer criteria are posted, 

those criteria are placed into a network transfer data packet to be sent to the server 10. There 



